Correct inconsistent casing of fdc3.timeRange #1240
Conversation
…tly as fdc3.timerange in a number of places
✅ Deploy Preview for fdc3 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
I added a reference from the task items for fdc3-dotnet 2.1 update to also fix this. |
There was a problem hiding this comment.
Seems that a majority of the implementation was all lower so I wonder if it would have made sense to stick to that in all cases, but for consistency across the API the camel casing makes more sense. I expect most usage is through the enum/constant declarations that are exported and not string literal hardcoding.
I agonized over that too - will the types have taken precedence or the examples and FDC3 workbench? In almost every cases there was a conflicting one on the same page or in the same schema. I decided to go with consistency with the rest of the standard in the end as I don't know that this type is heavily used as yet (it was originally created to support the I could add an admonition to the ref page for it, high;ighting the fact it had to be fixed... |
The
fdc3.timeRangecontext type is inconsistently cased in the FDC3 docs and codebase, sometimes appearing asfdc3.timerange. This PR corrects it such that it appears asfdc3.timeRangein all cases.Once approved the commit from this PR will need to be cherry-picked into a release/2.1.1 branch to release a corrected version of the 2.1 npm module.